refactor: Extract build and apply steps in the zk- and znode-controller - #1069

reconcile_zk built the ClusterResources itself and applied every
collection with its own inline loop, so the driver carried the apply
order, the orphan deletion and the resource specific error variants.

Extract all of that into an Applier, following the airflow and hbase
operators. KubernetesResources is now marked as either Prepared or
Applied, which makes it impossible to derive the cluster status from
resources that were only built. apply() destructures the resource set
exhaustively, so a new field fails to compile here instead of silently
never being applied.

Unlike the sibling operators, the apply module is declared in
zk_controller.rs itself, so the Applier is imported without `self` to
avoid a name collision with the module declaration.

The cluster conditions and the discovery hash were computed inline at
the end of reconcile_zk, from resources that happened to be in scope.

Move both into an update_status step, following the airflow and hbase
operators. It takes KubernetesResources<Applied>, so the type system
proves the status is derived from resources that were actually applied
rather than merely built. The discovery hash, which the sibling
operators do not have, becomes a private helper next to it.

reconcile_zk is now the dereference, validate, build, apply and
update_status pipeline and nothing else.

reconcile_apply created the ClusterResources, talked to ZooKeeper,
fetched the role Listener, built the discovery ConfigMap and applied it,
all inline, so the ZookeeperZnode controller was the only one left
without a pipeline.

Give it the same dereference, validate, build and apply structure as the
ZookeeperCluster controller. The Listener fetch moves into the
dereference step, where a missing Listener stays a non error so it can
never block finalizer removal, and its addresses become a validated
field on ValidatedZnode. Creating the znode inside the ZooKeeper
ensemble lives in the apply step as a free function, next to the
Applier, because it is a client side effect that the client free build()
cannot perform.

The discovery ConfigMap builders move to a shared discovery module, so
the znode controller no longer reaches into the cluster controller's
build tree.

Unlike the cluster controller, the resources carry no Prepared or
Applied marker: the ZookeeperZnode has no cluster conditions, so there
is no status step the marker could protect.

Skipping the discovery ConfigMap while the role Listener publishes no
addresses let the apply step delete the already published one as an
orphan, breaking consumers that mount it. Before the pipeline
extraction, the missing addresses aborted the run before
delete_orphaned_resources() ran, so this only surfaced now.

Follow the kafka-operator pattern instead: always write the ConfigMap,
with an empty ZOOKEEPER value while no address is known. The Listener
watch triggers a new run that fills the value in.

The znode controller had no tests at all. Add fixtures for it and cover
both ways the role Listener can block validation: addresses published
under an unexpected port name (ReadRoleListenerAddresses), and no
addresses at all, either because the Listener does not exist yet or
because the listener operator has not published its status
(NoRoleListenerAddresses).

The Listener fixtures move into a shared test_support module in
listener_addresses, so the cluster controller's tests can use them too.

Add a try_validate variant that takes a role Listener, and cover the
three outcomes: addresses published under an unexpected port name fail
with ReadRoleListenerAddresses, published addresses reach the validated
cluster sorted, and a missing or unpublished Listener validates to no
addresses rather than an error, which is what lets the build step still
write the discovery ConfigMap.

Assert the ZOOKEEPER, ZOOKEEPER_HOSTS, ZOOKEEPER_CLIENT_PORT and
ZOOKEEPER_CHROOT content for both the cluster and the znode variant,
that only ZOOKEEPER carries the chroot, and that a relative chroot is
rejected. The empty-address case is covered too, pinning that the
ConfigMap is written even while the role Listener publishes nothing.

The Listener fixtures now publish the secure client port, which is what
the role Listener serves while the fixture keeps TLS enabled.

…y-and-status-steps